Fix windows-arm64 timeout floor to use numeric comparison#129814
Merged
Conversation
Co-authored-by: JulieLeeMSFT <63486087+JulieLeeMSFT@users.noreply.github.com>
Copilot created this pull request from a session on behalf of
JulieLeeMSFT
June 24, 2026 18:12
View session
JulieLeeMSFT
approved these changes
Jun 24, 2026
Member
Contributor
There was a problem hiding this comment.
Pull request overview
Adjusts the windows_arm64 job timeout “floor” logic in the shared global build job template so that explicit timeouts above 75 minutes are correctly honored, avoiding unintended string/lexicographic comparisons in Azure DevOps template expressions.
Changes:
- Updates the conditional expression for windows_arm64 timeout selection to compare using a numeric-typed left operand (
lt(75, parameters.timeoutInMinutes)), ensuring numeric comparison behavior. - Keeps existing behavior for unset (
'') and ≤75 minute values, still applying the 75-minute floor.
Member
|
Converting to draft to wait for #129791 if it reduces the windows arm64 build time. |
JulieLeeMSFT
added
the
NO-MERGE
MichalStrehovsky
approved these changes
Jun 24, 2026
MichalStrehovsky
left a comment
MichalStrehovsky
left a comment
Member
There was a problem hiding this comment.
We need to unblock arm64 testing and I doubt anyone is going to review my PR anytime soon.
akoeplinger
approved these changes
Jun 24, 2026
This was referenced Jun 25, 2026
Open
hoyosjs
approved these changes
Jun 25, 2026
MichalStrehovsky
removed
the
NO-MERGE
Member
|
/ba-g the builds reset because of the Draft -> Ready for review state change, but the previous builds looked good. Let's unblock outerloops |
This was referenced Jun 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The windows-arm64 timeout floor in
global-build-job.ymlcompared a string-typed parameter against75withgt(parameters.timeoutInMinutes, 75). BecausetimeoutInMinutesis declared as a string (default: ''), ADO coerces the passed value (e.g.360) to a string andgt()keys conversion off the left operand's type — producing a lexicographic compare ('360' < '75'→ false). Explicit timeouts ≥ 100 silently collapsed to the 75-min floor, causingruntime-coreclr libraries-jitstressregswindows-arm64 to time out at 75 min (build 1474264).Changes
eng/pipelines/common/global-build-job.yml: Swapped the comparison so the integer literal is the left operand:gt(parameters.timeoutInMinutes, 75)→lt(75, parameters.timeoutInMinutes). ADO now converts the right operand to a number, yielding a true numeric comparison.Explicit values > 75 (e.g.
360) are now honored; values ≤ 75 still fall through to the 75-min floor. No other code or the parameter declaration was touched.